home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 8
/
QRZ Ham Radio Callsign Database - Volume 8.iso
/
pc
/
files
/
p_misc
/
netconf.arc
/
PACSAT.TXT
< prev
next >
Wrap
Text File
|
1988-12-10
|
37KB
|
726 lines
The following is the text of a paper submitted for the 7th ARRL
Networking Conference, October 1, 1988. It will appear in the
conference proceedings which will be published by the ARRL. Please
do not reprint this material without permission.
----------------------------------------------------
AMSAT's MICROSAT/PACSAT PROGRAM
Tom Clark, W3IWI
6388 Guilford Rd.
Clarksville, MD 21029
ABSTRACT
In 1989 AMSAT-NA plans to launch the first of a series of low-
earth orbit (LEO) sat-ellites dedicated to serving digital store-
and-forward message handling. These satellites are quite small
cubes, approximately 230 cm (9 inches) on a side weighing less
than 10 kg; this small size has led to our calling the project
MICROSAT. Despite the small size, the satellites are crammed with
state-of-the-art electronics. This paper will review the
development program leading to this design and some of the
technical details as well as describing how the terrestrial user
will make use of the resource. We are planning on the launch of 4
satellites using MICROSAT technology into LEO in early 1989, and
several more launches over the next 2 years.
A BIT OF HISTORY
In October 1981, the ARRL, AMRAD and AMSAT jointly hosted the
first Networking Conference when packet radio was in its earliest
period of development. Doug Lockhart (VE7APU) and the VADCG group
had put the first TNCs into our hands. Hank Magnuski (KA6M) and
the PPRS had the first digipeater on the air. In the D.C. area a
few of us (W4MIB, WB4JFI, K8MMO, W3IWI, KE3Z) were on the air
making funny sounds. The seed was planted!
On a warm sunny afternoon the following spring, at the AMSAT
lab at NASA Goddard, I took Jan King (W3GEY) aside and told him
of an idea I had. At the time we were building the AO-10
satellite which was to provide global scale communications from
its vantage point in high earth orbit (HEO). My idea was to
provide similar communications coverage from LEO using digital
store-and-forward techniques, albeit not in real time. The basic
idea was for the sender to uplink a message to the LEO satellite;
then at a later time when it was in view of the recipient, it
would be forwarded to him automatically.
After some more design work, I enlisted the aid of Den Connors
(KD2S) who was then spearheading the effort in Tucson which
became known as TAPR. Den and I started beating the bushes for
support for the program. When the ideas became known to AMSAT,
some of the old timers accused us of having lost our minds with
statements like "There aren't more than a couple of hundred
people on packet. Packet radio will never amount to anything.
etcetera etcetera". By the fall of 1982 we were starting to see
some ground-swell of support, so Den and I scheduled a special
meeting (to be held in conjunction with AMSAT's annual meeting)
which was to get inputs from packeteers in several groups on the
PACSAT concept. The second purpose was to try to see if we
couldn't come up with a national protocol standard; the result
was the adoption of AX.25 (for which some people STILL blame
me!).
Soon thereafter we found a potential sponsor who needed PACSAT
support to aid in disseminating information on technologies
appropriate to developing countries and thus was formed a tie
between AMSAT and the Volunteers in Technical Assistance (VITA)
and Gary Garriot (WA9FMQ). The VITA PACSAT project enlisted the
assistance of Harold Price (NK6K), Larry Kayser (VE3QB/WA3ZIA,
now VE3PAZ) and a number of others. The VITA/PACSAT team decided
to test their messaging concepts on a UoSAT spacecraft resulting
in UO-11's Digital Communications Experiment (DCE). The
partnership between VITA and the UoSAT group has continued, and
the UoSAT-D spacecraft (to be flown at the same time as our
Microsats) is the culmination of that effort.
In the meantime I told the Miki Nakayama (JR1SWB) and Harry
Yoneda (JA1ANG) of JAMSAT of our design concepts. The JAMSAT/JARL
team were able to implement many of these ideas in the mode "JD"
hardware on the Japanese JAS-1 (JO-12) satellite. They also
developed state-of-the-art reproducable 1200 BPS PSK demodulator
designs which have become important for future spacecraft
designs. Unfortunately the negative power budget on JO-12 has
limited the utility of an otherwise excellent spacecraft.
For the next couple of years any idea of our building a PACSAT
in the USA languished. First we were busy building the AO-13
satellite in consort with AMSAT-DL. The American dependence on
the Space Shuttle and the lack of suitable launches on which we
could hitchhike made opportunities few and far between. We looked
at low-thrust motors using water or Freon propellants to lift us
to a suitable LEO if we used the Shuttle's GASCANs. Two groups
flew small satellites ejected from GASCANs on the shuttle; one
was NUSAT, built by a of students and faculty at Weber State
College in Ogden, Utah. Then with the loss of the Challenger,
even those hopes for our building a PACSAT were dashed.
THE BIRTH OF MICROSAT
The scene now shifts to November, 1987 in a hotel room in
Detroit after the banquet at AMSAT's annual meeting. Jan King,
Bob McGwier (N4HY), Phil Karn (KA9Q) and I are sitting around at
1AM. Jan starts telling us of a concept that he and Gordon
Hardman (KE3D) have been thinking about. It involves a very
small, simple satellite, a 9" cube. He describes how five 8" x 8"
x 1.6" module "trays" would be stacked to make up the inner frame
of a satellite. Then on the small 9" x 9" solar panels would make
up the outside skin. He told us that he believed he had several
different potential launches that could carry several of these
cubes to LEO and asked us what we could do with the limited
space. By 3 AM we had a conceptual design, we had done link
margin calculations, we had selected a candidate CPU, and we had
estimated size, weight and power requirements for each of the
modules. The adrenalin flowing in our veins was at an all-time
high!
[ Figure 1. A photograph of the structural model
of the MICROSAT satellite.]
By early December we had refined the basic design. Dick
Jansson (WD4FAB) had done a complete mechanical design. We held a
preliminary design review at the AMSAT office and decided we were
GO!
While all this was going on, contacts were made with Junior
DeCastro (PY2BJO) of the Brazilian BRAMSAT group, Arturo Carou
(LU1AHC) of AMSAT-LU and with the NUSAT group at Weber State.
Each agreed to join the team and we settled on building four
satellites: The AMSAT-NA and AMSAT-LU satellites would be
classical PACSATs. The Weber State satellite would be a PACSAT
augmented by a TV camera which would send down pictures encoded
in normal AX.25 packet frames. The Brazilian satellite would be
the DOVE (Digital Orbiting Voice Experiment) which would "talk"
voice bulletins which could be copied on a normal HT.
PACSAT AND ALOHA
First we need to review a little packet radio theory. Let us
assume that the satellite operates with its transmitter and
receiver on different bands so that the communications links are
full-duplex. Let us also assume that there are many users, each
with similar capabilities, who are spread out over the entire
spacecraft "footprint". Let us further assume that traffic is
balanced -- whatever goes up to the spacecraft equals what comes
down, so the uplink and downlink channel capacity needs to be
balanced.
Since the ground-based users are spread out, the cannot hear
each other. Each will transmit at random in the hopes that his
packets make it thru. This is the classic ALOHA network
configuration with "hidden terminals". It can be shown that
collisions on the uplink channel will statistically reduce the
channel capacity so that only (1/2e) = 18.4% of the packets make
it thru. Thus, the downlink (on which there are no collisions)
can support about 5 times as much traffic as can a single,
collision-limited uplink.
There are two ways out of this dilemma. First, the uplink
users could use a data rate about 5 times the downlink; this
approach was taken by the AMSAT-DL designers of AO-13's RUDAK
experiment where a 2400 bit per second (BPS) uplink is balanced
against a 400 BPS downlink.
The second approach is to have multiple, separate uplink
receivers. The FO-12 satellite has four 1200 BPS uplink channels
balancing one 1200 BPS downlink.
MODEMS AND RADIOS FOR PACSAT
For our PACSATs, we have allowed for both solutions to the
ALOHA limit. Like FO-12, there are to be four user uplink
channels; however each of which can be commanded to support 1200,
2400, 4800 and possibly 9600 BPS uplinks. The downlink
transmitter will start its life at 1200 BPS, but higher rates
should be possible.
Our design was heavily influenced by a decision we made early
on: we would only use standards which were supported and
available "off the shelf". Thus when our PACSAT comes to life,
the ground user can use the identical hardware he uses for FO-12
today. The user's uplink will be at 1200 BPS, Manchester-encoded
FSK and the downlink will be 1200 BPS binary PSK. These standards
are supported by the TAPR and G3RUH modems, by the myriad FO-12
modems available on Akihabara in Japan, and by the DSP modems
that N4HY and I have been working on.
These "mo" modulator in these modems plugs into the mike jack
on a stock 2M FM radio, which we assume can be tuned in 5 kHz
steps. The satellite link margins should be such that 10-25 watts
into an omnidirectional antenna should be adequate (providing
everyone runs similar power).
The "dem" demodulator plugs into an SSB-capable 70 cm receiver
or all-mode transceiver, which needs to be tunable in 100 Hz (or
preferably finer) steps. The PSK downlink should be "Q5" even
with an omnidirectional antenna, providing the local noise level
is low.
The spacecraft's receiver has 15 kHz wide channels, regardless
of the bit rate programmed at the spacecraft. The 1200 BPS data
rate combined with an FM deviation of < 3 kHz, plus doppler
shift, plus 5 kHz steps on a typical FM radio just fit the 15 kHz
bandwidth. At some later date we will begin enabling selected
uplink receiver channels for higher data rates (like 4800 BPS),
but the user will now have to pre-steer the doppler and set his
frequency more accurately than 5 kHz. Also most stock FM radios
will not pass the 4800 BPS data rates without significant
modifications.
ONBOARD PACSAT
Let us now discuss some of the features of the satellite's
architecture. The electronics is divided into modules, with the
space inside each module being about 7.8" x 6.5" x 1.5". The
mechanical layout has five of these modules stacked atop each
other as shown in Figure 2, which we will describe from top to
bottom.
|
|
| 2M uplink antenna
|
|
_______!_______
| RECEIVER |
|_______________|
| TSFR |
|_______________|
| BATTERIES+BCR |
|_______________|
| CPU |
|_______________|
| TRANSMITTER |
|_______________|
/ \
/ \
/ 70 cm downlink \
/ antenna \
Figure 2. PACSAT LAYOUT
RECEIVER
The core of the receiver is the Motorola MC3362 single-chip FM
receiver, couple with a stock NDK crystal filter with 15 kHz
bandwidth centered at 10.7 MHz. The filter has very good skirts,
with 80-90 dB ultimate rejection. The input to the 3362 is an IF
in the 40-50 MHz range. The 1st LO in the 3362 is crystal
controlled to mix to 10.7 MHz. Following the filter, the 3362's
second mixer is driven from a crystal controlled 8.9 MHz 2nd LO
to produce a final IF of 1.8 MHz selected for best linearity of
the MC3362's FM detector (discriminator).
The MC3362's FM detector drives two matched data filters, each
of which uses one section of a TLC274 CMOS op amp; the 2-pole
Butterworth filters are optimized for 1200 and 4800 BPS data
rates. A CD4066 analog switch selects the output of one of the
two filters to drive the data clipper section of the 3362. The
appropriate filter is selected by the CPU.
In addition, one section of the TLC274 produces an analog
signal in the 0-2.5v range corresponding to the user's frequency
(the "disc meter") and another produces a 0-2.5v analog signal
corresponding to the user's signal strength (the "S meter").
All this circuitry takes up 1.5" x 3" on the receiver's
circuit board and draws under 20 mW (< 4 ma at 5V). This circuit
is replicated five times to provide the 4 user uplink channels
plus a command/control channel.
The design of this portion of the receiver was done by W3IWI
with invaluable inputs from Eric Gustavson (N7CL).
In front of this bank of five FM IF strips is a fairly
conventional GaAsFET preamp with a noise figure < 1 dB. A narrow-
band 3-stage helical filter provides selectivity between the
GaAsFET preamp and a dual-gate MOSFET mixer which is driven by a
crystal-controlled LO at about 100 MHz. The output of the MOSFET
(at 40-50 MHz) drives five emitter followers to provide isolation
between the five FM IF stages. The design of these stages was
done by Jim Vogler (WA7CJO) and W3IWI.
The total power consumption for the entire receiver is about
150 mW.
[As a side note -- the receiver modules designed for PACSAT
have been made easily reproducable, with very few "twiddles". All
components, including the coils and helical filter are off-the-
shelf items purchasable from sources like Digi-Key. It is
anticipated that TAPR and/or AMSAT will make single-channel
receiver kits available for use in dedicated packet link
applications if there is enough interest].
TSFR
For PACSAT, this is a dummy module. TSFR means "this space for
rent", and is reserved for future expansion.
POWER SYSTEM
The Battery Charge Regulator (BCR) module contains the NiCd
battery pack, the charger that conditions solar panel power to
charge the batteries, and the switching regulators that produce
the +5 and +10 v power needed by each module. The BCR and
regulator design was done by Jon Bloom (KE3Z) with help from
Gordon Hardman (KE3D).
The solar panels make use of high-efficiency silicon cells
with back-surface reflectors (BSR). BSR technology is new, but it
allows for much higher efficiency; if a photon does not produce
electricity as it passes thru the silicon on its way in, the
reflector allows a second chance to "grab" it. The solar panel
electrical and mechanical design was done by Jan King (W3GEY) and
Dick Jansson (WD4FAB), and the solar panels are being produced
under contract by Solarex.
The price of space qualified NiCd batteries has become
prohibitive, so new, low cost approaches have been adopted. Larry
Kayser (VE3PAZ) and his group in Ottawa proved with UO-11 that if
good, commercial grade batteries were purchased, they could be
flight qualified. The qualification procedure involves extensive
cycling to characterize the charge-discharge curve and
temperature performance, X-raying the batteries to look for
internal structural flaws, then selecting only the best cells,
and then finally potting the batteries.
While the solar panels produce about 14 watts, when averaged
over a whole orbit (some time is spent in eclipse), and after
losses in power conditioning about 7-10 watts is available.
CPU
In many ways the flight computer is the key to PACSAT. At the
time we were selecting the CPU, the SANDPAC group in San Diego
were finishing the first pre-production run of the new PS186
network switch. Based on their experience, we selected a similar
architecture. The flight CPU is based on the NEC CMOS V-40 CPU
(quite similar to an 80C188). The flight CPU includes EDAC (Error
Detection and Correction) memory for storage of critical
software, plus bank-switched memory for data storage (i.e. "RAM
Disk"). We hope to fly upwards of 10 Mbytes on each PACSAT
(limited only by available space and the price of memory chips).
The CPU, when running hard draws about 2 watts of power.
A companion paper by Lyle Johnson (WA7GXD) and Chuck Green
(N0ADI) describes the CPU's architecture in much more detail. A
paper by Bob McGwier (N4HY) and Harold Price (NK6K) describes
the multi-tasking software. Jim DeArras (WA4ONG) is converting
Lyle and Chuck's wire-wrapped prototype to multi-layer circuit
board. The ROM-based bootloader to allow recovery from disasters
has been written by Hugh Pett (VE3FLL) whose code had previously
saved the day on UoSAT.
TRANSMITTER
At the time of this writing, the transmitter is still in the
design phase, so some of these parameters may change. The
transmitter will be BPSK modulated, and will have its power
output changeable by ground command. The current plans are for
two power levels, about 1.5 or 4 watts. The transmitter starts
out with a crystal oscillator at 109 MHz, and is followed by two
doublers to 436 MHz. This design is being done by Stan Sjol
(W0KD). Gordon Hardman (KE3Z) is working on a power amplifier
using a Motorola MRF750 driver and a MRF752 output stage. The
collector voltage on the driver stage will be command selected to
be either the +5 or +10v bus to provide power agility. This
collector voltage may be amplitude modulated to provide some
time-domain shaping to minimize the transmitted bandwidth.
Transmitter development is also being done in Canada by Bob
Pepper (VE2AO).
GLUE
The myriad mechanical details were all sorted out before we
cut a single piece of metal by Dick Janssen (WD4FAB); Dick made
extensive use of modern CAD techniques and all drawings were done
with AutoCAD (see Figure 3). In Boulder, Jeff Zerr has been
shepherding the detailed mechanical layout and find what pieces
don't fit. A "show and tell" model was built by ???? with help
from Dick Daniels, and a mechanical mockup for vibration testing
has been built by Jeff Zerr.
When we began developing the Microsat concept, we took a look
at problems that had been major hassles on earlier satellites.
High on the list were problems in building a wiring harness and
testing individual modules. We also wanted a design that allowed
a "cookie cutter" approach to manufacturing since we anticipate a
number of launches in the next few years. We came to the
conclusion that we needed to develop a bus-like wiring approach
with all modules having similar interfaces, and we needed to
minimize the number of wires. I took on the task of solving this
problem and defining the electrical "glue" that holds the system
together.
After exploring a number of options, the design we adopted was
to use hi-rel DB25 25-pin connectors on each module and use a 25-
wire bus made like a flexible printed circuit. Of the 25 wires,
about 40% are used for power distribution, about 40% to carry
packet data from the receiver to the CPU and from the CPU to the
transmitter, and the final 5 wires are used to let the CPU
control functions in the individual modules and for analog
telemetry.
[ Figure 3. Part of one of WD4FAB's drawings
showing MICROSAT assembly details. ]
AART
In order to squeeze all these command, control and telemetry
functions into only five wires, we have built a very small (7
inches long!) LAN with the CPU acting as the network master node
and each module being a slave node. Data communications from CPU
to module consist of two byte packets; the first byte (with the
MSB=1) addresses up to 128 slaves, and the second byte (with
MSB=0) is a 7-bit received data field to be passed to the module
(RXD). On receipt of a valid address, the module automatically
sends back two 8-bit bytes (TXD) of data on another wire. All
data is sent with normal asynchronous protocols.
On the CPU side, this async data is generated and received by
the UART built into the V40 chip. The protocol is easily
simulated on a PC, so testing each module does not require a
complete working spacecraft.
In each module, we use a clever IC: the Motorola MC14469F
Addressable Asynchronous Receiver/Transmitter (AART). The 14469
is a 44-pin surface mount part (also available as a 40-pin
conventional DIP) which implements the protocol just described
with very few external parts. It has separate pins for the 7
address bits, the 7 RXD bits and the 16 TXD bits.
The 7 RXD bits are used for a number of functions. The MSB of
this word is used to select analog vs. digital functions, with
the control data specified by the remaining 6 bits. For digital
functions, the 6 bits are treated as two 3-bit nibbles which
constitute the address and data for three CD4099 addressable
latches, resulting in 24 bits of digital data being available for
control functions in the module.
When the MSB selects analog functions, the 6 bits are taken as
addresses for CD4052 CMOS analog multiplexer chips which decode 6
discrete analog telemetry samples plus four thermistors. When a
module is selected in analog mode, the selected analog signal is
switched onto two wires (signal plus return) in the 25-wire bus,
and when the module is de-selected the two wires are floated. A
single, fast 8-bit 0-2.5v A/D converter in the CPU handles all
spacecraft analog telemetry. Each module is responsible for pre-
conditioning its analog signals to fit the 0-2.5v range.
All these parts, including some op amps to condition the
thermistor signals, plus the DB25 spacecraft bus interface
connector and tie-points for all signals needed in the modules
are fitted onto a 7.8" x 1.5" board which is mounted against one
wall of the module frame. The interface boards in each of the
"slave" modules are identical except that the AART chip is
strapped to different addresses. This small board has been dubbed
the AART board. It was designed by W3IWI and Bob Stricklin
(N5BRG). Each board requires 5 mW of power (about 1 ma at 5v).
THE OTHER MICROSATS
DOVE
So far we have described the two Microsat PACSATs: those
sponsored by AMSAT-NA and AMSAT-LU. The BRAMSAT DOVE spacecraft
is still in the final design phases, but it will be built from
many of the same pieces and will have the same general mechanical
layout. DOVE will transmit its digitized voice signals in the 2M
band with conventional FM modulation. Rather than designing a
different receiver system, we have decided to have the command
uplinks also on 2M; the DOVE transmitter will turn itself off
every few minutes to listen for commands. Only the transmitter
module is different for DOVE. As of the time of this writing we
are planning to use differentially-encoded voice synthesis (e.g.
"delta modulation") with up to 4-bit encoding of the differential
data. Preliminary design on the speech synthesizer has been done
by Bob McGwier (N4Y) and W3IWI and is being simulated using our
DSP hardware.
NUSAT
The Weber State NUSAT MICROSAT is different mechanically from
the PACSATs, shown in Figure 4.
|
|
| 2M uplink antenna
|
|
_______!_______
| TV CAMERA |
|_______________|
| CPU |
|_______________|
| BATTERIES+BCR |
|_______________|
| RECEIVER |
|_______________|
| TRANSMITTER |
|_______________|
/ \
/ \
/ 70 cm downlink \
/ antenna \
Figure 4. NUSAT LAYOUT
The major difference is that NUSAT has a CCD TV camera in the
top module. The TV camera is connected to a high-speed multi-
channel "flash" A/D converter which can digitize incoming video
signals at 10 MHz sample rate. Its data is stored in memory which
can also be accessed by the CPU. The Weber TV camera module and
CPU were placed in adjacent modules so that the memory could be
easily dual-ported.
The sample rate for the A/D converter and the input signal
source can be selected by the CPU. The primary signal source is a
CCD TV camera equipped with an electromechanical iris built into
its lens. The iris's aperture can also be controlled by the CPU.
The camera's field of view allows a 350 km square to be imaged
from the satellite's 800 km high orbit. The camera assembly
occupies about 1/4 of the space in the module. It is planned to
use video data compression techniques to minimize the downlink
data requirements; Weber State and AMSAT-NA plan to have software
to support these advanced video techniques available around
launch time.
Weber State also plans to try a 1269 MHz video uplink. Video
data from this uplink will be digitized by the "flash" A/D
converter and loaded into the dual ported memory, just like data
from the CCD camera. It is also hoped that the TV camera can be
used as an visible and IR spectrometer covering the 400 to 2000
micrometer wavelength band.
The other NUSAT modules are nearly identical to the PACSATs
and NUSAT could be also turned into a PACSAT merely by loading
different software.
The Weber State team consists of a number of students, staff
and faculty members from the Center for Aerospace Technology
(CAST) including Bob Twiggs, Bob Summers and Chris Williams.
THE FIRST MICROSAT LAUNCH
AMSAT-NA and the UoSAT group have worked with the European
Space Agency and Ariannespace to develop a new launch capability
for very small satellites. This will be first tested on the
launch of the SPOT-2 Earth Resources Satellite in early 1989. On
that flight there will be SIX small satellites -- our four
Microsats and two somewhat larger UoSAT spacecraft. The orbit is
nearly ideal -- sun synchronous at 800 km altitude, much like the
Oscar-8 orbit. At mid-latitudes, passes will occur twice per day
at predictable times around 10:30 A.M. and 10:30 P.M. local time.
USING THE MICROSAT SATELLITES
As we mentioned before, our PACSATs and Weber State's NUSAT
use ordinary AX.25 packet protocols. To receive any of the three,
you merely need to add a PSK demodulator to your 70 cm receiver.
The uplink requirements are modest and the same as FO-12. At a
later time, when transmitter technology permits and user loading
dictates, some of the receiver channels will be reprogrammed to
higher speeds. But initially, if you are able to use the FO-12
satellite, then you are all set.
The spacecraft software that you will see will be designed for
message handling, and the code is being written by Bob McGwier
(N4HY) with inputs from a number of us. The initial software will
probably look very much like a W0RLI/WA7MBL BBS system, with a
few enhancements. First of all, the prompt that the satellite
will send to you will have two telemetry numbers in it -- these
are your signal strength and discriminator meter readings. The
discriminator meter should be invaluable in helping you center
your signal in the receiver's passband and its use will become
mandatory as we migrate to higher uplink speeds. The spacecraft
software will support multiple, simultaneous users. There may be
commands that allow you to request specific telemetry information
from the satellite.
I anticipate that much of the utility of these satellites will
be as an augmentation of the terrestrial HF long-haul message
forwarding networks. If this proves to be true, then fully
automated gateway stations will make heavy use of the satellite
capabilities.
Therefore it is important that we design both the ground-based
and flight software to work together smoothly. We have had
ongoing discussions with the writers of BBS code (like W0RLI and
WA7MBL) to make sure that both sides of the link will be ready on
launch day. In these discussions we have been devising schemes so
that the burden of maintaining routing information resides on the
ground. New forwarding protocols in which the receiving station
tells the sender what message addresses it can handle are being
defined. It is likely that these will be coupled with heirarchial
domain-oriented addressing schemes like are used by TCP/IP
protocols. A user on the W3IWI BBS would have an address like
W3XYZ@W3IWI.MD.USA and if I were operating as a gateway for the
MD/VA/DE/PA/NJ area, I would be able to inform the spacecraft to
send me any messages so addressed.
At the same time that "connected" mode activity is going on,
the satellite will be sending UI "broadcast" (i.e. UNPROTO)
frames with telemetry and bulletins of interest to all. On NUSAT,
digitally encoded pictures of the earth will be sent as UI frames
which will be reassembled by the user on the ground.
THE FUTURE
We have reason to believe that there are a number of launch
opportunities to LEO for very small satellites. We have designed
our Microsats to be easily reproducable. As new capabilities
(perhaps 9600 or 19,200 BPS modems? Experiments to fit into the
TSFR module? ) are developed, we feel there will be opportunities
to fly them.
We anticipate non-amateur uses of our technology. Initial
discussions with scientists specializing in oceanography and
seismology have shown that they have a need for low-cost data
collection systems from remote locations. We anticipate a scheme
for a commercial licensee to "sell" our technology in these
markets. Just like royalties from TAPR's TNC2 project have
provided resources for future development activities in packet
radio, we hope that Microsat royalties will provide a similar
legacy for advancing amateur satellite technology.
We also see that the Microsat technology provides a perfect
way for fledgling space groups associated with other AMSAT
organizations around the world and with universities to develop
their own satellite programs. Don't be surprised to see Microsats
being built by people from many nations.
The spacecraft operating software can be uploaded from the
ground. As NK6K and N4HY discuss in their companion paper, the
software we will be flying is the most complex ever attempted in
the amateur satellite program. It probably will crash! We have
designed in several safeguards to make this possible. With this
flexibility, we also have the ability to try new things. Perhaps
we will see new mail-handling protocols developed which use
datagrams. Perhaps we will see a PACSAT programmed to be a TCP/IP
FTP file server. As the old adage states:
IT'S ONLY SOFTWARE !
--------------------
PARTING COMMENTS AND ACKNOWLEDGMENTS
The most important "glue" that holds a project like this
together is the project manager. We are indeed fortunate to have
Jan King (W3GEY), with his wealth of experience, his contacts in
the aerospace industry, his mother-hen persistence in reminding
us of the rigors of space, and his compulsive personality to make
sure everything happens.
Jan's "glue" binds together a team of high-strung, emotional
prima donnas who are equally compulsive. Many of the team members
have invested a lot of 3AM mornings working on this project! All
the team members have had to wear very thick skins to withstand
the FLAME ON! communications blasts some of us are prone to emit.
Bob Mcgwier, Dick Jansson and Lyle Johnson all deserve special
credit for service above and beyond the call of duty.
This project has significant players spread out all over North
America, with major activities in NJ, MD, VA, FL, CO, UT, AZ, TX
and CA. Unfortunately amateur radio communications are inadequate
to keep such a dispersed team working together. We have relied
heavily on commercial electronic communication channels,
particularly AMSAT's network on GTE TeleMail and TAPR's channels
on CompuServe, plus a lot of phone calls. Every few months we get
a number of the people in one place and lock the door to make
sure everyone REALLY understands what is happening.
We have made heavy use of various CAD tools during the
development activities. Mechanical layout was done with AutoCAD.
ORCAD was heavily used for developing schematics, wiring lists,
parts lists and net lists. CAD PCB layout used Smartwork, ORCAD
PCB and Tango. See Figure 5 for an axample of some of this use of
CAD techniques.
[ Figure 5. One of W3IWI's ORCAD schematics
of the MICROSAT receiver IF strip.]
We have done some experimentation using higher-level
networking for technical communications to move CAD data using my
TOMCAT FTP file server which has a SLIP port in addition to being
on the "real" network.
There are two organizations not mentioned earlier that have
contributed a lot to this project: TAPR and the ARRL. For many of
the volunteers working on this project, the distinction between
TAPR and AMSAT is fuzzy since they seem to wear two hats. In
addition to the TAPRites working on this project, TAPR has made
vital contributions of funds and hardware, without which we
couldn't make it. Special thanks to Andy Freeborn (N0CCZ) for
helping to make the TAPR/AMSAT interface smooth. At the ARRL labs
in Newington, Paul Rinaldo and Jon Bloom have made many vital
contributions.
From the AMSAT organization, two people deserve a lot of
credit. Vern Riportella (WA2LQQ) was instrumental in arranging
the AMSAT-LU and BRAMSAT participation in the project. Martha
Saragovitz has acted as mother confessor, paid bills, handled
meeting logistics and kept smiling thru it all, despite
repeatedly crying out "Where's the money coming from?".